1. Field of the Invention
This invention relates to remotely establishing the specific or dynamic properties of a computer system. More specifically, it relates to remotely establishing trust in properties of a computer system.
2. Related Art
Current Trusted Computing Group (TCG) use cases provide the means for remote parties to attest to the software state of a computer system/platform. The software state includes measurements of the software chain, and might include configuration files used to initialize or customize a software module. The attestation method, as described in TCG documents, begins with a Core Root of Trust for Measurement (CRTM) that measures the software and possibly configuration files of the next layer of software to run. Each layer in turn measures the next layer before calling it. Digests of these measurements are extended through a one-way hash function into Platform Configuration Registers (PCRs) contained in a Trusted Platform Module (TPM). The measurement names and values are also appended to a measurement list.
During the remote attestation process, a set of PCRs is quoted—digested, and digitally signed with a trusted Attestation Identity Key (AIK). The remote party/system validates the AIK certificate issued by a trusted privacy certificate authority, the digital signature of the quote, and the integrity of the measurement list by comparing it to the PCR state included in the quote. Once the measurement list is trusted, the remote system uses it to determine whether the attesting system is running trusted software.
Current uses measure known, expected, constant, system-independent data. A typical measurement is a software stack, from bootstrap loader, through Operating System load, and finally application load. Remote systems doing an attestation are expected to have known good values. Even when other data such as configuration files are measured, the literature envisions a limited number of variations among systems, a relatively homogeneous environment.
By measuring data common to many systems, and by storing only static data, not data generated at run time, the remote system needs to store only a small list of trusted measurements (software modules or configuration files), and can use that list to attest a large number of systems across an enterprise. While this attestation is valuable for trusted computing, it does not address establishing trust in data that may be specific to a system or even data that may be generated or changed as the system runs.
For example, there are currently mechanisms to establish secure communication tunnels, usually based on public key certificates (e.g., SSL, IPSEC, and Web Services Security). There are also techniques to establish properties of remote systems using the TPM or other core root of trust elements. Unfortunately, these two separate mechanisms do not ensure that the system for which properties are established during remote attestation is the same system at which the protected tunnel ends. This is essential for establishing security guarantees in distributed environments. One known solution is to create trusted third parties that “vouch” that certificates used during remote attestation and certificates used to establish secure tunnels belong to the same system. Drawbacks of known solutions include (among others): (1) third parties are difficult to establish; (2) third parties are currently unable to solve key revocation in a scalable and cost-efficient way; and (3) it is extremely difficult to find commonly trusted parties in heterogeneous distributed environments.
In view of the foregoing, there exists a need for a solution that solves at least one of the deficiencies in the related art.